First off, I would like to state that I do not appreciate being personally attacked. Regardless of what your own background may be, I too can back up my statements with experience and expertise. In fact, my primary role has been front-end development for years, and I have a very strong background with regards to leveraging XHTML, CSS, and JavaScript, and combining the technologies in all the ways that they can be. Some of your own comments are particularly uninformed or improperly phrased, particularly when speaking of adding JavaScript to process things. This is (generally) not something that is done on a server, and as such will not slow the server down in the least. Rather, it is intended as a __client-side__ technology, meaning that the processing is done on the user's computer.
Moving on... It is a well known fact that IE6 is severely lacking in many aspects related to its support of standards as they are today, regardless of where IE6 stood when it was first released. Additionally, I'd love to see documentation supporting your comment that 90% of bugs are made up. Granted, many of the issues have workarounds, or are caused by incorrect usage, but in the case of creating a purely CSS zebra-table solution, there isn't a perfect solution regardless of what browser or technologies one is willing to use. For instance: * using hard-coded classes adds overhead in terms of file size and maintenance * using dynamically generated classes adds overhead on the server and in terms of file size * adding classes via JavaScript adds overhead on the client (user's computer) and will not work if JavaScript is disabled or unavailable These different issues must be balanced depending upon the particular use case. If all the data for the table is stored in a database, and a server-side language extracts the data into a table with customizable properties, classes can be added to each row accordingly, making it simple to style them via CSS on the front-end. If the data is hard- coded, then adding classes by hand may be viable, particularly for small datasets or for instances in which the developer knows their editor well enough to perform text replacements via CTRL-F3 or whatever other key combination is set up. In many cases, though, the dataset will be large enough that updating hard-coded classes when rows are added/moved/removed is tedious, and the HTML may not be consistent enough for a simple Find/Replace to work appropriately. Though a database is likely to be the more maintainable solution, such technology is not always available, or the resources to maintain it are not. In such a case, JavaScript-based solutions are often the best that can be used. My argument for JS in this case is not intended to negate the obvious benefits of pure CSS solutions, but was instead suggested (note that I did not insist upon it in the least in my first response) due to the particular constraints given in the original post. As far as what I meant in terms of "robustness", I was referring to the ease of use related to the add/move/remove scenario. Obviously having any sort of script (be it JavaScript, PHP, Python, or otherwise) process the page in order to generate the classes adds some overhead. In the case of JavaScript, there is no additional slow-down on the server, as it is a client-side script. Instead, the generation occurs when the page has loaded already on the user's machine, and for all but the most enormous tables (or extremely slow machines), would be nearly instantaneous. Standards compliance is not complete in most browsers. While CSS 2.1 is supported by IE6 __for the most part__, there are some selectors that are incorrectly implemented, others that are not implemented at all, and many instances where developers are oblivious of either these gaps in support, or their own incorrect usage. I'll state once again that robustness does not equal efficiency. Robustness is defined on Wikipedia as "the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance." In this case, as I've mentioned before, I'm using the term to relate to the ability of a JS-generated solution to maintain the appropriate striping of rows regardless of changes in the row order or contents (add/move/remove scenarios). I certainly do submit to the fact that having pure XHTML + CSS will generally be more efficient with respect to load time or processing requirements. Finally, my response relating to immediate support by browsers of the most updated specifications and standards was a __theoretical__ and __ideal__ circumstance, not at all to be confused with reality. It was also a very generic argument, not limited simply to this situation but instead wrapping the very broad range of instances when pure CSS solutions are not possible given the state of the web. Again, a utopian web would have every user using the most updated versions of their browser of choice, and each browser creator would focus not only on improving their interface for usability and accessibility, but also upon maintaining standards compliance to make the job of Web design and development that much easier for those of us who have such careers. Utopia has never been possible, and never will. Every time a browser comes closer to complying with standards, a new standard or specification is released (case in point: the upcoming release of HTML5, and CSS3). Maintaining such compliance is an extensive task, and I applaud browser creators for their ongoing efforts. While IE6 may once have been the high-point of the Web, its ability to keep up with newer and better browsers is rapidly decreasing. Sure, corporations are often locked into using it due to licensing or support issues. Many companies require IE6 due to security software that would otherwise need to be updated (and often at great cost). Regardless of where the users are coming from, though, a site owner must pander to the demographics of those who view their site. As such, if a JavaScript-aided solution is needed, why not use it? Necessity often overrules the optimal solution. My only intent in posting anything here is to provide a quick judgement upon what __might__ be the right solution for the person asking for help. Often times, I will be proven wrong. There may be a much more elegant solution out there which I have failed to think of. In some cases, a solution I propose may not even work. If you wish to make the effort to add to conversations on this (or any other) list, it seems much more appropriate to provide details that are helpful to the original poster, rather than wasting the time attacking someone just because their proposal doesn't meet with your particular dreams. Having an open mind and being willing to accept unorthodox (or maybe simply less-than-optimal) solutions are traits of a dynamic and flexible developer, and are not something to be scoffed. Such openness often provides the developer with the ability to present out-of-the- box ideas that, through further discussion, can change the face of development at a much more fundamental level than the original issue being addressed. Try to keep that in mind... -- Jake Kronika Gridline Design www.gridlined.com -- -- You received this because you are subscribed to the "Design the Web with CSS" at Google groups. To post: css-design@googlegroups.com To unsubscribe: css-design-unsubscr...@googlegroups.com
